Prefer lazy initialization and caching for resource-intensive objects like the Conscrypt security provider. Creating a new Provider instance on every transport creation can lead to significant performance overhead and high memory usage.

We can introduce a static lazy holder class to cache the Conscrypt provider instance safely, ensuring it is only initialized once and does not cause class-loading issues if Conscrypt is not present on the classpath.

    private static final String[] PQC_GROUPS =
        new String[] {"X25519MLKEM768", "SecP256r1MLKEM768", "X25519"};
    private static final HttpTransportFactory INSTANCE = new DefaultHttpTransportFactory();

    private static class ConscryptProviderHolder {
      private static final java.security.Provider INSTANCE = createProvider();

      private static java.security.Provider createProvider() {
        try {
          return Conscrypt.newProvider();
        } catch (Throwable t) {
          LOG.log(
              Level.FINE,
              "Conscrypt native libraries not available. Falling back to JDK TLS.",
              t);
          return null;
        }
      }
    }

Are there known checked exceptions? If not, catching Exception is fine but catching Throwable might hide larger problems. e.g. Even if a version mismatch is ignored here, it might blow up in other places.

It doesn't throw any CheckExceptions. I'll change this so that it catches Exceptions instead. Online suggests the possibility of wrapped SSLSockets or proxied ones failing the Conscrypt check, but that seems to throw an Exception instead.

If there is a version mismatch of a JNI issue, that should be caught in the Conscrypt initializaiton logic and would be caught by the conscryptProvider == null check above.

where Conscrypt is unsupported

What error would we run into?

I'm not too sure. I think it's a linkage error but i'm not too familiar with native API logic as to which error message is thrown

Do we want to catch linkage error though? Unless we know this could cause incompatible issues, I think catching Exception below makes more sense.

@blakeli0 Update the groups as I found out these are the MKLEM groups that Conscrypt supports: https://github.com/google/conscrypt/blob/44a36308a64e3f872192baabd7c3b5819dc618a2/CAPABILITIES.md?plain=1#L94-L96

This test is a duplicate of the same test in HttpJsonConscryptUtilsTest.

Removing this test. I don't think it needs to be tested. Jetski added this in for coverage

This test would always pass if we change a value in the group. We should use String literals for assertion.

I don't think we need to test this. I'm going to remove this

Cool, I don't see this showcase test reference it yet though. Also I don't think we should expose a field as public just for testing.

I see this list is different from last time I reviewed. Is there a definitive list we can reference?

#13853 (comment)

Found after additional showcase testing. Conscrypt's list of supported algos